the original goal of using Vec<u8> (like using [u8;N] in the past) was to make it more natural for rust developers. i.e. these are the types they would use anyway, with no conversion or new API necessary. Given that we've moved away from that goal over time, I'm fine making this change

Couple things:

• can we ease instantiation of Bytes with a bytes![1,2,3] macro to match other bespoke types?
• in what situations will a user use Vec<u8>, get the 32x blowup in encoding size, end up with the wrong blob, and ask in alloy chat what they did wrong?

@prestwich Regarding the first point, there's currently a macro_rules bytes! macro that lets you create a Bytes from string literals. If we were to move to a proc macro, bytes![...] could expand to Bytes::from(vec![...]) for non-str inputs.

macro_rules! bytes {
    () => {
        $crate::Bytes::new()
    };

    ($($s:literal)+) => {{
        // force const eval
        const STATIC_BYTES: &'static [u8] = &$crate::hex!($($s)+);
        $crate::Bytes::from_static(STATIC_BYTES)
    }};
}

For the second point, something that's nice about this is that bytes now expands to Bytes. You'd need to put []uint8 in an event, say, for the generated struct to actually have a Vec<u8> if I understand things correctly.

you can add a macro rules arm like this:

    [$($inner:literal),+] => {{
        // force const eval
        const STATIC_BYTES: &'static [u8] = &[$($inner),+];
        $crate::Bytes::from_static(STATIC_BYTES)
    }}

    #[test]
    fn bytes_macros() {
        const B1: Bytes = bytes!("010203040506070809");
        const B2: Bytes = bytes![1, 2, 3, 4, 5, 6, 7, 8, 9];

        assert_eq!(B1, B2);
    }